home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-mimemhs-harpoon-02.txt < prev    next >
Text File  |  1993-04-28  |  10KB  |  402 lines
  1.  
  2. draft                          HARPOON                          Jan 93
  3.  
  4.  
  5.                                  HARPOON
  6.       Rules for downgrading messages from X.400/88 to X.400/84 when
  7.               MIME content-types are present in the messages
  8.  
  9.                      Tue Apr 13 15:50:23 MET DST 1993
  10.  
  11.  
  12.                          Harald Tveit Alvestrand
  13.                                SINTEF DELAB
  14.                    Harald.T.Alvestrand@delab.sintef.no
  15.  
  16.  
  17.                               Jim Romaguera
  18.                               NetConsult AG
  19.                          Romaguera@netconsult.ch
  20.  
  21.  
  22.                                Kevin Jordan
  23.                         Control Data Systems, Inc.
  24.                          kej@mercury.udev.cdc.com
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.     Status of this Memo
  32.  
  33.          This document is an Internet Draft.  Internet Drafts are
  34.          working documents of the Internet Engineering Task Force
  35.          (IETF), its Areas, and its Working Groups. Note that other
  36.          groups may also distribute working documents as Internet
  37.          Drafts.
  38.  
  39.          Internet Drafts are draft documents valid for a maximum of
  40.          six months. Internet Drafts may be updated, replaced, or
  41.          obsoleted by other documents at any time.  It is not
  42.          appropriate to use Internet Drafts as reference material or
  43.          to cite them other than as a "working draft" or "work in
  44.          progress."
  45.  
  46.          Please check the I-D abstract listing contained in each
  47.          Internet Draft directory to learn the current status of this
  48.          or any other Internet Draft.
  49.  
  50.          If consensus is reached in the IETF MIME-MHS Interworking
  51.          Working Group, it will be submitted to the IESG asking that
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Alvestrand et al         Expires Sep 13 1993                  [Page 1]
  58.  
  59. draft                          HARPOON                          Jan 93
  60.  
  61.  
  62.          it be recommended to the IAB as a Proposed Standard protocol
  63.          specification.
  64.  
  65.          This RFC updates RFC 1328.
  66.  
  67.          HARPOON stands for Holistic Approach to Reliable Provision of
  68.          Open Networking, and is used solely to catch the eye of
  69.          readers.
  70.  
  71.          Please send comments to the MIME-MHS mailing list
  72.          <mime-mhs@surfnet.nl>
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Alvestrand et al         Expires Sep 13 1993                  [Page 2]
  115.  
  116. draft                          HARPOON                          Jan 93
  117.  
  118.  
  119.     1.  Introduction
  120.  
  121.     Interworking between X.400(88) and MIME is achieved by [MAPPING],
  122.     which modifies RFC-1327 [RFC 1327], which specifies the
  123.     interworking between X.400(88) and RFC-822 based mail.
  124.  
  125.     Interworking between X.400(88) and X.400 (84) is achieved by RFC-
  126.     1328 [RFC 1328]. That document does not describe what to do in the
  127.     case where body parts arrive at the gateway that cannot be
  128.     adequately represented in the X.400(84) system.
  129.  
  130.     This document describes how RFC-1328 must be modified in order to
  131.     provide adequate support for the scenarios:
  132.  
  133.     SMTP(MIME) -> X.400(84)
  134.  
  135.     X.400(84) -> SMTP(MIME)
  136.  
  137.     It replaces chapter 6 of RFC-1328.
  138.  
  139.     NOTE: A desireable side-effect of HARPOON is that a standardized
  140.     method for the identification and transmission of multimedia and
  141.     binary data (like spreadsheets) between X.400/84 UAs is achieved.
  142.  
  143.     While this method is not compatible with current proprietary
  144.     approaches, we believe that it requires less invasive changes to
  145.     current UAs than other possible methods.
  146.  
  147.  
  148.     2.  Basic approach
  149.  
  150.     The approach is to imagine that the connection X.400(84) <->
  151.     SMTP(MIME) never happens. This, of course, is an illusion, but can
  152.     be a very useful illusion.
  153.  
  154.     All mail will therefore go on one of the paths
  155.  
  156.     X.400(84) -> X.400(88) -> SMTP(MIME)
  157.  
  158.     SMTP(MIME) -> X.400(88) -> X.400(84)
  159.  
  160.     when it goes between a MIME user and an X.400(84) user.
  161.  
  162.     The approach at the interface between X.400(88) and X.400(84) is:
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171. Alvestrand et al         Expires Sep 13 1993                  [Page 3]
  172.  
  173. draft                          HARPOON                          Jan 93
  174.  
  175.  
  176.     o    Convert what you can
  177.  
  178.     o    Encapsulate what you have to
  179.  
  180.     o    Never drop a message
  181.  
  182.     Of course, for X.400/88 body parts that are already defined in
  183.     X.400/84, no downgrading should be done. In particular, multi-body
  184.     messages should remain multi-body messages, IA5 messages
  185.     (including IA5 messages encoded as Extended Body Parts) should
  186.     remain IA5 messages, and G3Fax messages should remain G3Fax
  187.     messages.
  188.  
  189.  
  190.     3.  Conversion rules
  191.  
  192.  
  193.     3.1.  EBP conversions to Basic
  194.  
  195.     Some body parts are defined by X.400(88) as having both a Basic
  196.     form and an Extended form. These are listed in Annex B of X.420.
  197.  
  198.     For all of these, the transformation from the Extended Body Part
  199.     to the Basic Body Part takes the form of putting the PARAMETERS
  200.     and the DATA members together in a SEQUENCE.
  201.  
  202.     This transformation should be applied by the gateway in order to
  203.     allow (for example) X.400(88) systems that use the Extended form
  204.     of the IA5 body part to communicate with X.400(84) systems.
  205.  
  206.  
  207.     3.2.  Encapsulation format
  208.  
  209.     For any body part that cannot be used directly in X.400(84), the
  210.     following IA5Text body part is made:
  211.  
  212.  
  213.     -    Content = IA5String
  214.  
  215.     -    First bytes of content: (the description is in USASCII, with
  216.          C escape sequences used to represent control characters):
  217.  
  218.          MIME-version: <version>\r\n
  219.          Content-type: <the proper MIME content type>\r\n
  220.          Content-transfer-encoding: <quoted-printable or base64>\r\n
  221.          <Possibly other Content headings here, terminated by\r\n>
  222.          \r\n
  223.  
  224.  
  225.  
  226.  
  227.  
  228. Alvestrand et al         Expires Sep 13 1993                  [Page 4]
  229.  
  230. draft                          HARPOON                          Jan 93
  231.  
  232.  
  233.          <Here follows the bytes of the content, as per [MAPPING], encoded
  234.          in the proper encoding>
  235.  
  236.  
  237.     All implementations MUST place the MIME-version: header first in
  238.     the body part. Headers that are placed by [RFC-1327] and [MAPPING]
  239.     into other parts of the message MUST NOT be placed in the MIME
  240.     body part.
  241.  
  242.     This includes RFC-822 headings carried as heading-extensions,
  243.     which must be placed in a new IA5 body part starting with the
  244.     string "RFC-822-HEADERS", as specified in [RFC-1327], Appendix G.
  245.  
  246.     Other heading-extensions are still handled as described in chapter
  247.     5 of RFC 1328: They are dropped.
  248.  
  249.     Since all X.400(88) body parts can be represented in MIME by using
  250.     the x400-bp MIME content-type, this conversion will never fail.
  251.  
  252.     In the reverse direction, any IA5 body part that starts with the
  253.     token "MIME-Version:" will be subjected to conversion according to
  254.     [MAPPING] before including the body part into an X.400(88)
  255.     message.
  256.  
  257.  
  258.     4.  Implications
  259.  
  260.     The implications are several:
  261.  
  262.  
  263.     -    People with X.400(84) readers who have the ability to save
  264.          messages to file will now be able to save MIME multimedia
  265.          messages
  266.  
  267.     -    People who can use features like the "Mailcaps" file to
  268.          identify what to do about a bodypart can now grab MetaMail or
  269.          MHN and achieve at least some multimedia functionality
  270.  
  271.     5.  Security considerations
  272.  
  273.     The security considerations in [MIME] and [MAPPING] (beware of
  274.     trojans that can hit you if your UA automagically starts programs
  275.     for you) are now relevant also for X.400(84) systems.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285. Alvestrand et al         Expires Sep 13 1993                  [Page 5]
  286.  
  287. draft                          HARPOON                          Jan 93
  288.  
  289.  
  290.     6.  Authors' address
  291.  
  292.     Harald Tveit Alvestrand
  293.     SINTEF DELAB
  294.     N-7034 Trondheim
  295.     NORWAY
  296.     Harald.T.Alvestrand@delab.sintef.no
  297.  
  298.     Kevin E. Jordan, ARH215
  299.     Control Data Systems, Inc.
  300.     4201 Lexington Avenue N
  301.     Arden Hills, MN  55126
  302.     USA
  303.     Kevin.E.Jordan@mercury.oss.arh.cpg.cdc.com
  304.  
  305.     James A. Romaguera
  306.     NetConsult AG
  307.     Mettlendwaldweg 20a
  308.     3037 Herrenschwanden
  309.     Switzerland
  310.     Romaguera@netconsult.ch
  311.  
  312.  
  313.     7.  References
  314.  
  315.     [MIME]
  316.          N. Borenstein, N. Freed, MIME: Mechanisms for Specifying and
  317.          Describing the Format of Internet Message Bodies.  RFC 1341
  318.  
  319.     [RFC-1327]
  320.          S.E. Hardcastle-Kille, Mapping between X.400(1988) / ISO
  321.          10021 and RFC-822.
  322.  
  323.     [RFC-1328]
  324.          S.E. Hardcastle-Kille, X.400 1988 to 1984 downgrading.
  325.  
  326.     [MAPPING]
  327.          H.T. Alvestrand, R.S. Miles, M.T. Rose, S.J. Thompson,
  328.          Mapping between X.400 and RFC-822 Message Bodies Internet-
  329.          Draft, (June, 1992).
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342. Alvestrand et al         Expires Sep 13 1993                  [Page 6]
  343.  
  344. draft                          HARPOON                          Jan 93
  345.  
  346.  
  347.     Table of Contents
  348.  
  349.  
  350.      Status of this Memo ........................................    1
  351.     1 Introduction ..............................................    3
  352.     2 Basic approach ............................................    3
  353.     3 Conversion rules ..........................................    4
  354.     3.1 EBP conversions to Basic ................................    4
  355.     3.2 Encapsulation format ....................................    4
  356.     4 Implications ..............................................    5
  357.     5 Security considerations ...................................    5
  358.     6 Authors' address ..........................................    6
  359.     7 References ................................................    6
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399. Alvestrand et al         Expires Sep 13 1993                  [Page 7]
  400.  
  401.  
  402.